REMARKS 

Claims 102-126 have previously been indicated to be allowable. In the Office 
Action dated July 30, 2008, Claims 102-126 were rejected as anticipated by Solomon 
'591. The examiner's new rejection over Solomon is based on a misunderstanding of the 
disclosure of Solomon. Applicant respectfully requests withdrawal of the rejection and 
allowance of all claims. 

Background 

The preset application is directed to a method of processing rebates. It is generally 
understood that a rebate requires a customer to take some action subsequent to a purchase 
transaction in order to receive a rebate (cash or otherwise.) The typical action is for the 
customer to request the rebate and provide evidence that the rebated product was actually 
purchased. A rebate presents a unique problem not associated with instant discounts and 
coupons (where credit is given at the point-of-sale), - the customer must provide 
evidence after the fact that the rebated product was actually purchased. Customers who 
request rebates who have not actually purchased the rebated products present a huge 
fraud threat to the rebate processor. In the past, customers have been required to provide 
"UPC" codes from packages or other product specific codes in order to evidence that the 
rebated product was purchased. 

Present Application 

The pending claims are directed to a method whereby an identifier which 
identifies the purchase transaction (but not the specific products) is assigned and provided 
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to the customer at the point of sale. Thus the customer is able to evidence his purchase of 
a rebated product solely from the submission of the assigned transaction identifier. 
The Cited Art 

Solomon is directed to a method of rebate processing. However, "the transaction 
identifier" disclosed in Solomon and the use of that identifier is in stark contrast to the 
"transaction code" defined and used in the claims of the present application. In order to 
fully appreciate the difference, it is necessary to discuss the rebate procedure disclosed in 
Solomon. 

Solomon requires first that the customer identify the product for which a rebate is 
requested. Solomon discloses that the customer initiates the rebate process by identifying 
the product purchased and submitting this information to a rebate processing center. 
(Col. 3, 11. 64-66). Fig. 6 provides an example of a website for selecting a purchased 
product. Once a product is selected, the rebate processing center provides a rebate 
request screen to allow the customer to provide information regarding the purchased 
product and the rebate. (Col. 8, 11. 45-51). Fig 7 provides an example of a web site for 
the customer to provide the information relating to a rebated product. 

Next, the rebate processing center assigns a transaction identifier to the rebate 
request submitted by the customer and creates an entry in a transaction table. (Col. 6, 11. 
63-65). Fig. 4 illustrates a transaction table containing transaction information organized 
in rows indexed by the transaction identifier, where each row represents a request for a 
rebate from a customer. (Col. 6, 11. 7-11). The customer is then provided with a rebate 
request form with a transaction identifier. (Col. 9, 11. 23-26). Fig 8 is an example of a 
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rebate request form that can be printed out by the customer containing the transaction 
identifier that a customer can use to affix the product UPC symbol and the cash register 
receipt to show proof that the rebated product was actually purchased. Upon receipt of 
the rebate request form from the customer, the rebate processing center attempts to match 
the rebate request form with the entry created in the transaction table using the 
transaction identifier. (Col. 13, 11. 63-66). 

In summary, Solomon represents a prior art rebate processing system which 
requires the customer to provide identification of the specific product purchased in order 
to validate the rebate request. Note that the transaction identifier is assigned by the rebate 
processing center when a customer initiates a rebate request, and it is used for internal 
tracking purposes by the rebate processing center to match a submitted rebate request 
form to an entry in the transaction table. 

The Claim Rejections 

Each of the independent Claims 102, 104, 1 10, 1 16, 121 and 124 includes the 
limitations of providing a customer with a transaction code identifying the purchase 
transaction in which a rebated product was purchased, and using the transaction code to 
validate that the rebated product was actually purchased. None of these claimed 
limitations are found in Solomon, and the examiner's rejection is based on a 
misunderstanding of the different meanings ascribed to the term "transaction code" as 
claimed in the present application, and the term "transaction identifier" as used in 
Solomon. 
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The present claims require that the transaction code be assigned during the 
purchase transaction and be provided to the customer. The customer then can provide the 
transaction code to a rebate processing center as proof that a purchase of a rebated 
product took place. The rebate processing center uses the transaction code to confirm 
from the records of the retailer that the rebated product was actually purchased in the 
transaction specified by the transaction code. 

In contrast, Solomon discloses that a transaction identifier is assigned by the 
rebate processing center and is used for tracking purposes. The transaction identifier is 
not, and can not be used to confirm that a rebated product was actually purchased. For 
example, in Solomon a customer can submit a rebate request and receive a transaction 
identifier without first having actually purchased a product. Solomon discloses other 
methods for deterring a fraudulently submitted request, none of which is based on a _ 
transaction code assigned during the purchase transaction. 

Thus, the claim limitations identified above are clearly missing and the rejection 
of the independent Claims 102, 104, 1 10, 116, 121 and 124 based on Solomon is 
improper. For the reasons described above, reconsideration and withdrawal of the 
rejection of independent Claims 102, 104, 1 10, 1 16, 121 and 124 is requested. 

The remaining claims depend from their respective independent claims and are 
therefore allowable with their respective independent claims without regard to the further 
patentable limitations respectively recited therein. 


DM2U614576.1 


5 


Reconsideration and withdrawal of the rejections and the immediate allowance of 
the application is accordingly solicited. 


Respectfully submitted, 



Patrick D. McPherson Reg. No. 46,255 


DUANE MORRIS LLP 
505 9 th Street, N.W., Suite 1000 
Washington, DC 20004 
Telephone: (202) 776-7800 
Telecopier: (202) 776-7801 

Dated: November 6, 2008 
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